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(54) Method for providing a service for users of a telecommunication network 



(57) The invention concerns a method for providing 
a service for users of a telecommunication network. 
Service calls requesting the execution of the service for 
an respective one of the users are routed to a service 
switching exchange of the telecommunication network 
or are respectively routed to one of several service 
switching exchanges of the telecommunication network. 
A corespondent service request is sent by the respec- 
tive service switching exchange, that has received the 
respective service call, to a service control facility or to 



one of several possible service control facilities. For 
each such service request received from the or each 
service switching exchange a service session object, 
which is able to interact and communicate via an object 
infrastructure with other objects in a object oriented 
computing environment, is created within the or each 
service control facility and the respective service ses- 
sion object controls the execution of the service for the 
respective service call. 
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Description 

The invention concerns a method for providing a 
service for users of a telecommunication network 
according to claim 1 , a method for provisioning the exe- 5 
cution of a service logic function within a service control 
facility of a telecommunication systems according to 
claim 15 , a service control facility for connecting to one 
or several service switching exchanges of a telecommu- 
nication network according to claim 1 6 and a processing to 
node for a service control facility connected to one or 
several service switching exchanges of a telecommuni- 
cation network according to claim 18. 

Telecommunication services can be provide 
according to the Intelligent Network Architecture. rs 

A user of a telecommunication network requests a 
service by dialing the number dedicated to the service. 
The call with this number is routed through the telecom- 
munication network to a service switching exchange 
which recognize this call as call requesting the service, zo 
Then, this service switching exchange communicates 
via a data network with a service control facility, the so 
called service control point. This service control point 
contains a service logic which contains a description of 
the method that has to be executed to provide the serv- ss 
ice to the calling user. By a request of the service 
switching exchange the execution of this method by the 
service logic is initiated and the requested service is 
provided to the requesting user. 

This service logic is realized as a single process 30 
handling all calls one after the other. Each of them going 
through a single queue. Each call is associated with a 
context allowing the sate of the call not to be lost 
between user interaction. The service is executed 
through a finite state machine, taking as input the TC AP 35 
message an the context of the call. 

The disadvantage of this approach is that this archi- 
tecture of provisioning services is that within the service 
control facility an incoming request for an service has to 
wait for execution until the current one has been proc- 40 
essed out. Therefore, the rate of service requests that 
can be handled by the service control facility is strictly 
limited. 

Accordingly, it is a primary objective of the present 
invention to increase the number of service requests 45 
that can be handled by an processing node that is 
involved in the execution of services for users of an tel- 
ecommunication network. 

This objective is solved by a method for providing a 
service for users of a telecommunication network so 
according to the teaching of claim 1 , a method for provi- 
sioning the execution of a service logic function within a 
service control facility of a telecommunication systems 
according to the teaching of claim 1 5 , a service control 
facility for connecting to one or several service switching 55 
exchanges of a telecommunication network according 
to the teaching of claim 16 and a processing node for a 
service control facility connected to one or several serv- 



ice switching exchanges of a telecommunication net- 
work according to the teaching of claim 18. 

The underlying idea of this invention is that for each 
service request received from a service switching 
exchange a service session object, which is able to 
interact and communicate via an object infrastructure 
with other objects in a object oriented computing envi- 
ronment, is created within the control facility and the 
respective service session object controls the execution 
of the service for the respective service call. Therefore, 
the service architecture is not longer based on a func- 
tional design and technologies like multithreading or 
multi processing can be applied. 

Due to the introduction of a object oriented comput- 
ing environment and the special object design 
described above, the processing of the service requests 
can be distributed and this proved high salability and IT 
platform independence. The redesign of the service 
logic according to this approach allows for easy service 
interworking personalisation, distribution and maintain- 
ability of the software. The design pattern allows for tak- 
ing all benefits from object oriented programming. 

Furthermore, it allows to introduce multithreading. 
The direct benefit is that a service session, that means 
the processing of a service request, is not blocked by 
the execution of another one. 

The use of a factory allows to implement several life 
cycle policies for the service session objects. 

It is further advantageous 

to implement each service by a dedicated CORBA 
server. Each call to the service is handled then by a 
single CORBA object. 

to managed the creation of a service session object 
by a service dedicated factory. 

to set the interface definition of a service session 
object as TCAP mapped over IDL. 

By the use of CORBA servers the service control 
facility implementation Is simplified and salability is 
ensured. 

Other advantageous embodiments of the invention 
are described in the subclaims. 

The present invention will now be described with 
reference to the accompanying drawings, wherein 

Fig. 1 is a block diagram presenting the architecture 
of a telecommunication system containing a serv- 
ice control facility according to the invention. 

Fig. 2 is a block diagram presenting a first object 
architecture of the telecommunication system. 

Fig. 3 is a block diagram presenting a second object 
architecture of the telecommunication system. 
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Fig. 4 is a block diagram presenting a third object 
architecture of the telecommunication system. 

Fig. 5 is a block diagram presenting a object archi- 
tecture of a service switching exchange for the tele- 
communication system. 

Fig. 1 shows a telecommunication system TS with 
an telecommunication network KN1 , a subscriber termi- 
nal T assigned to a subscriber A, a communication net- 
work KN2 and two service control facilities SCPIand 
SCP2. 

The telecommunication network KN1 is for example 
a telephone network. It is also possible that this network 
is a data network or a communication network for mixed 
data speech and video transmission. 

From the exchanges of the network KN1 two spe- 
cial designed exchanges SSP1 and SSP2 are showed. 
This exchanges are service switching exchanges that 

M .; Mn _ M ..u«*L»: nM i- I - nnn -r_ 
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exchanges service- request calls from the subscriber of 
the network are routed. When such a service switching 
exchange receives such a service request, he sends a 
corresponded request via the network KN2 to one of the 
two service control facilities SCP1. The service is than 
provided under the control of the respective one of the 
service control facilities SCP1 and SCP2. 

Each of the service control facilities SCP1 and 
SCP2 provides one or several services S and realize a 
service control function. 

The communication network KN2 is preferable a 
data network, especially according to the SS7 signaling 
protocol. It is also possible that this network is a LAN 
(Local Area Network), a MAN (Metropolitan Area Net- 
work) or a ATM (Asynchronous Transfer Mode) network. 

Preferable, the service switching exchanges SSP1 , 
SSP2, and the communication between them and the 
service control facilities SCP1 , SCP2 are designed 
according to the Intelligent Network Architecture 
(according to the service switching point and according 
to the communication between the service switching 
point and the service control point), described for exam- 
ple in the ITU-T Q. 121 4 Recommendation. 

If a user wants to start an service S, he dials a spe- 
cific number for that service. The local exchange will 
route this call to the nearest service switching 
exchanges and this will trigger the service switching 
functionality SSP to start the service. This is done by 
sending a request to the SCP to start executing a Serv- 
ice Logic Program (SLP). An SLP is specific for each 
service, it will instruct the network on how to handle the 
service. It will execute service logic, statistic logic, data- 
base logic, charging logic, etc. It will also provide 
instructions for the switch (e.g. create the second leg of 
the call) and Intelligent Peripherals (IP) (e.g. announce- 
ment machines). The INAP protocol is used for this, and 
INAP messages are transported in TCAP messages 
between the SCP and SSP. 



When designing a distributed application, first the 
possible system components to be distributed are iden- 
tified (i.e what the objects of the system are and how 
they will be grouped into larger objects that will be dis- 
s tributed). 

The breaking down of the SCP into objects offers 
some possibilities. Figures 2 to 3 depict these organized 
into different architectures. All state information for han- 
dling one call was kept together and that all needed 
10 data was organized into objects. So, one possibility for 
SCP objects is a script object that executes the service 
logic for one call and an object per data object. 

The values of the data objects are kept into a data- 
base, so having data objects that hide the use of a data- 
's base is preferable (i.e. certain independence on the 
database). The catch lies in the fact that making these 
objects CORBA objects gives us a considerable over- 
head when methods (e.g. to read or write attribute val- 
ues) are called on them. So, the system performance 

20 would become unacceptable. 

The script object could be decomposed into a serv- 
ice execution engine and a SIB graph. So, SIBs could 
become distributed objects too. If database objects are 
distributed , this offers the possibility to execute a SIB on 

25 the machine were the particular data object resides. We 
can envisage a scheme where there is a control entity 
(a script) that executes SIBs remotely (possibility of hav- 
ing more overhead) ore a scheme where control is 
passed from SIB to SIB. This trade off between getting 

30 the data and running a script on one machine and run- 
ning parts of a script (SIBs) where the data resides is 
certainly worth to be investigated. 

The SSPs main functionality is to provide a hook 
between the call processing and the IN system. An SSP 

35 server must at least have an object that bridges 
between the normal Call Control Function (CCF) and an 
object that bridges between the Switching Function 
(SF). Also an object that bridges between Specialized 
Resources (SRF) (e.g. announcement equipment), 

40 seems to be obvious. In Figure 4, these objects are 
depicted as a Switching Control, Call Control and Spe- 
cial Resources Object. We also need an object, Call 
Handler (CH) that interlaces with the SCP and the other 
objects in the SSP. There are two possibilities: there will 

45 be only one that handles all calls, or several, each han- 
dling one call. If we have several, existing only for the 
duration of the call, we also need a corresponding fac- 
tory object to control the lifecycle of these objects. 
In the following is given the architecture of an SSP 

so server on CORBA For the Switching Control, Call Con- 
trol and Special Resources objects we could have two 
approaches. In the first approach they are only interface 
objects between the proprietary Application Interface 
(API) of existing software. In the second approach they 

55 would control the hardware directly, what implies provid- 
ing a CORBA interface to Switching Control, Call Con- 
trol & Special Resources. In theory this would be the 
best solution, since the approach would give an overall 
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consistent software architecture, in this case special 
special IDL adapter interface have to be designed. 

A SMP is responsible for service control and moni- 
toring. In order to be able to control services, the SMP 
does not need to be a DPE object. What is needed is 
that the objects that are controlled (e.g. script) provide 
an interface to do so. For monitoring we need an SMP 
object that is able to receive 'events' from the objects 
that are being monitored. In our research prototype we 
defined and implemented a trace control as an example 
on what is possible as management functionality on the 
SCP. 

In the previous section we have described a 
number of possibilities for CORBA objects in an IN 
Architecture. In this section we will group certain of 
these CORBA objects into a specific architecture. The 
sequence of the architectures can be seen as possible 
evolution scenario, starting from current days service 
provisioning, especially IN, products. 

The basis of the first architecture is the usage of a 
distributed database for data distribution and CORBA 
distribution for distributed SCP . this architecture is 
designed to interface with existing SSPs, so the SSP is 
not a CORBA object. Since this architecture was used 
to implement a research prototype, we elaborate on it 
more than the others. Figure 3 depicts the architecture. 

The basic components in the architecture are: 

the script: a CORBA object that handles exactly 
one call 

the SLI (Service Logic Interface), a CORBA object 
that handles a TCAP dialogue for, and interfaces 
with the SSP. 
the distributed DB. 

Existing IN service scripts can encapsulated in 
Script objects. 

A Script object also contains the Service Data and 
Call Context related to a particular call, and one Script 
object is instantiated per call. The interface of the Script 
object contains operations that represent the TCAP 
messages that the Script receives during its execution. 

A special Service Logic Interface (SLI) object 
receives the #7 messages from the SSP and dispatches 
them to the corresponding script object instantiation, 
using the ORB services. The interface of the SLI object 
contains the TCAP messages that can be sent to it. One 
SLI object is instantiated per call. 

Since the Script and SLI objects exist only during 
the lifetime of a call corresponding factory objects are 
used to create and destroy them. Data objects are not 
CORBA objects, they are implemented as C + + objects. 
This approach hides the use of a particular database 
from the service logic. 

It's possible to use as database for example Oracle, 
SQLNET or ObjectStore. The SMP has not be consid- 
ered; we could have used the proprietary mechanism to 
send status information to it, or defined it as a CORBA 



object with an appropriate IDL interface. 1 

However as an example on what is possible, its 

easy possible to design and implement a small trace 

control system; each server has a tracer object, the 
s trace control part of the SMP can call methods to turn 

traces on particular implementation objects on and off. 

The SMP also manages the database (using SQLNET). 
A script and a SLI are CORBA objects, how they 

are distributed over servers is a deployment issue. A 
to CORBA server is a process running at a particular node 

in the system. There is one SLIServer in the system that 

interfaces with the SSP. It has one CORBA object, the 

SLFactory, that is always present when the server is 

running. 

15 The main purpose of this object is to create new SLI 
objects when new calls are started (when a TCAP dia- 
logue is opened). The SLIServer is deployed in the 
node that has the #7 hardware and software installed. 
The system can have a number of ScriptServers, one 

so per available node. 

This server also has a factory object, that exists 
during the lifetime of the server itself. This factory object 
is registered in the CORBA Naming service, so that an 
SLI can find it In this way service logic distribution is 

25 facilitated. Adding more processing power to the system 
just means installing the new machine, running the 
ScriptServer on ft, and the next time the SLI looks for a 
ScriptFactory a new possibility is available. The same 
mechanism also provides some reliability, when a 

30 machine goes dawn for some reason, the SLI will simply 
not get a reference to that ScriptServer any more. Note 
that the ScriptFactory is also to best candidate to put a 
management interface on (e.g. to change the service 
characteristics), since it is always available as long as 

35 the server is running. 

The interface between SLI and Script is defined to 
be asynchronous and in terms of TCAP primitives 
(BEGIN, INVOKE. RESULT, ...). This option is advanta- 
gous, since one of the requirements is to reuse existing 

40 IN product software. Another option is to define this 
interface in terms of INAP primitives. 

The difference between a CORBA object, a 
(CORBA) server and a process must be clear. A 
CORBA object implements an interface and runs within 

45 a CORBA server. The CORBA server itself is one proc- 
ess that runs on a host (or node). This definition is 
important for the relation between a script and a call. In 
the current ALCATEL IN product implementation a 
script is a process that handles different calls, and 

so keeps a different call context for each of those. This is 
done for performance reasons, starting up a separate 
process (script) for each call takes some time. 

We could adapt a similar approach (one script han- 
dles n calls) in these architectures, but the fact that a 

55 script has multiple contexts is not that dean and it is 
possible to deal with the performance issue by having a 
CORBA server with multiple scripts (each handling one 
call). So, it is better that in this architecture, a host can 
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run one or more CORBA servers, each running different 
script objects that each handle a specific call. 

The CORBA server is similar to the script in the cur- 
rent IN product, but the problem of handling multiple 
contexts is shifted from the application programmer to 
the CORBA platform. 

A step further in this sequence of architectures, as 
second architecture, is to breakdown the script object 
into its components. As known, IN services are 
designed as a number SIBs that are nodes in a service 
logic graph. The execution of the script means execut- 
ing SIBs and moving to the next SIB depending on data 
and responses coming from the SSR In stead of design- 
ing this as a monolithic piece of software (from the 
SCE), it could be designed in terms cooperating SIBs. 
As known, the IN capability set 1. SIBs are not suffi- 
ciently defined to used them as they are. This resulted 
in IN platform providers having their own set of SIBs 
derived from the standard and software from SIBs is not 
reusable among platforms. 

When SIBs are defined as CORBA objects this sit- 
uation could be broken and service providers would be 
able to design there own services, reusing existing SIBs 
(source code). 

Having SIBs as independent CORBA objects offers 
the possibility to execute the SIBs in different places. In 
stead of getting the data (using a distributed database, 
or using CORBA objects) to the place where the script 
or SIB is executed, we could start the SIB on the 
machine where the data is located. This brings benefits. 
We can envisage a scheme where there is a control 
entity (a script) that executes SIBs remotely or a 
scheme where control is passed from SIB to SIB. 

A third architecture breaks with traditional IN prod- 
uct in the sense that it also makes the SSP a CORBA 
object. In the previous architectures, for reliability rea- 
sons, it is still necessary that CORBA servers are 
deployed on machines that are interconnected on a reli- 
able LAN. In practice, with the current DPE implementa- 
tions (TCP/IP) this means putting the machines in the 
same location. This technology restriction prevents 
putting the SSP on the DPE, since in practice SCP and 
SSP sites are located on different places. However, 
technology evolves and DPE providers (e.g. IONA) are 
looking into the possibility of porting their product to 
other transport protocols, e.g. #7 links for telecommuni- 
cation purposes. When this happens the step to making 
the SSP a CORBA object is not that big. In this case, the 
SLI object would not be needed anymore, since the 
SSP object could take over its role. When a call is 
started it gets a reference to a ScriptFactory and asks to 
create the script object itself. It could then communicate 
with this object directly. Also the language used in this 
communication (INAP encapsulated in a TCAP based 
interface) can be simplified. This interface could be 
defined in terms of INAP primitives (e.g. 
provide_instruction(args), join(args)). This would 
improve (simplify) the system design and implementa- 



tion, since the TCAP layer disappears for the application 
programmer. One could say that when CORBA is used, 
the application programmer must only be concerned 
with the application layer of the communication, not with 

5 the session layer (when TCAP is used). 

The final step would be to extend integrate a termi- 
nal (as proposed by TINA). This would mean a major 
change in user equipment. However this change is not 
unfeasible if we consider the fact that more and more 

io users get connected to the internet over their telephone 
lines. And the technology needed to have the DPE 
extended to the terminal is similar to this. The benefit of 
this would be that the terminal to network protocol could 
become much richer than just passing DTMF tones as 

rs numbers. 

The above described architectures provides a solu- 
tion to make especially IN platforms more scalable. 
Since interworking with and evolution from existing 
products is important we presented a sequence of 

so architectures that can be seen a possible evolution sce- 
nario. 

As example a implementation procedure according 
to the architecture 3 is described in the following: 

A Credit Card Calling service which existed for the 

25 UNIX based IN Release existing Alcatel product is to 
implement. The Credit Card Call service is a -typical" IN 
service and allows a call from any terminal to be billed 
to a particular card number. To set up that call, the user 
has to enter a card number, a PIN code and the destina- 

30 tjpn number. If the entered data is correct, the call is 
completed to the destination address and charged to 
the user's card. 

An SSP simulation stub was used to generate the 
TCAP dialogue for the Credit Card Call. The SSP stub 

35 is a CORBA object that sends and receives the same 
TCAP messages that an SSP would. The SSP stub is 
capable of simulating different call scenarios, can gen- 
erate different call loads and can repeat a scenario an 
arbitrary number of times. 

to Another general issue for the use of CORBA in an 
IN oriented service provisioning architecture is the inter- 
working of CORBA-based IN with legacy IN applica- 
tions. 

This interworking can be achieved with the use of 
45 Adaptation. It is related to the way a CORBA based 
infrastructure can communicate with the legacy of 
switching systems, namely SSPs. 

There are two approaches possible: 

so 1 ) Definition of an Adaptation Unit which which is an 
application level bridge that provide the mapping of 
SS.7 and TCAP primitives into IDL invocations. 
This approach is similar to one taken by the 
XoJIDM group for the CORBA/CMIP gateway [4][5]. 

55 The result of their works can be reused especially 
the static mapping of GDMO/ASN.1 to IDL inter- 
faces. 

In order to minimise the impact on existing sys- 
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tems, CORBA should provide framework services 
and tools in order to achieve this mapping. The 
availability of such framework will allow interwork- 
ing of CORBA-based IN with a variety of existing 
hardware such as SCPs and HLRs. 5 

Such application level bridge should be charac- 
terized by high availability and high performance 
without being a bottleneck for a distributed system. 
However for the required real-time performance, 
this is an intermediate solution towards full IN to 
CORBA-based systems. 

This approach would involve building an IDL 
interface to represent application level protocols 
such as MAP and I NAP and others which are based 
on the TCAP layer. The TCAP layer provides a is 
'ROSE-like' asynchronous RPC service over the 
SCCP layer. And basing the bridge on TCAP will 
exclude the use of circuit related signaling protocols 
such as ISUP and TUP from the solution. 

Like in the XoJIDM approach, there should be 20 
a static translation of the INAP/TCAP specification 
to IDL interfaces which will be done by a dedicated 
compiler. Thus, any INAP dialect can be converted 
to appropriate IDL interfaces. These applications 
level bridges would implement these IDL generated ss 
interfaces and dynamically perform conversion 
between IDL-derived types and their ASN.1 equiva- 
lents. 

CORBA nodes using the protocol specific 
bridges would generally run two servers, one each 30 
for processing outgoing and incoming invocations. 
Since TCAP is a connectionless service the gate- 
way will have to maintain state in order to match 
invocations to responses and exceptions. 

35 

2) Usage of SS7 as an Environment Specific Inter- 
ORB protocol (ESIOP): 

A possible solution is to map the CORBA GIOP 
on top of SS7 or to build a new Extended protocol 
(ESIOP) on top of the SS7 layers. <to 

The ESIOP solution would essentially use an SS7 
protocol as a transport for the GIOP protocol. CORBA 
objects would be visible across the SS7 network in 
exactly the same manner as they would be across the 45 
Internet with the CORBA HOP. This would allow as ORB 
to use existing SS7 infrastructure as transport 

It should be noticed that existing signaling networks 
were never dimensioned to support the sort of traffic 
which will be exchanged by CORBA nodes. However, so 
there is a potential benefit in this approach by exploiting 
the fault tolerant nature of the SS7 network. 

The first issue here is the choice of SS7 protocol 
access level for this solution. The two principal choices 
are TCAP and SCCP : 55 



GIOP at TCAP level: 

It should be possible to use TCAP for carrying 
GIOP messages since IT is essentially a ROSE-like 
service. Services which make use of TCAP must define 
their operations using ASN.1 modules. It is envisaged 
that ASN.1 macros would be used to define the opera- 
tion set: Request Reply, Cancel Request. LocateRe- 
quest, LocateReply, CloseConnection and 
MessageError. These operations correspond to the 
GIOP primitives. The gateway would be responsible for 
converting CDR format, of the form used by GIOP, into 
a form transportable using ASN.1 types (possibly as an 
opaque buffer with BER encoding). 

While it should be possible in principle to use TCAP 
as the basis for the ESIOP, it is not suitable because of : 

the complexity of the implementation, 
the overhead incurred in by the TCAP layer in addi- 
tion to basic transport 
• the asynchronous nature of the protocol. 

ESIOP at SCCP level: 

The other choice for implementing the SS7 ESIOP~ 
is at the SCCP level. The SCCP provides services cor- 
responding to the OSI-RM network layer functionality. It 
can operate in both connection-oriented and connec- 
tionless mode. It should be feasible to use the SCCP to 
transport GIOP messages although the ESIOP code 
may be required to perform its own transport layer func- 
tions (e.g. end-to-end flow-control and segmenta- 
tion/reassembly). It should be possible to address 
CORBA nodes using the 'Global Title' mode of SCCP 
addressing. It would appear that using SCCP as the 
basis for an ESIOP for the SS7 network would be the 
best approach. 

Following requirements are advantageous for a 
object oriented environment an infrastructure in which a 
service session object interacts (described by hand of 
the CORBA environment): 

In terms of functional requirements, CORBA should 
provide : 

asynchronous Invocation model and support for 

group communication in the ORB; 

proper hooks for extending the ORB with security, 

transaction and replication mechanisms; 

node management and minimal object iifecycle 

facilities; 

a time service and native monitoring facilities for 
capturing both computational and engineering 
events; 

support for multithreading with flexible event-to- 
thread mappings. 

The non-functional requirements of CORBA are 
concerned with : 
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_ identifying the level of salability and object granular- 
ity that the ORB should meet in the IN context; 

_ identifying the performance level that the ORB must 
achieve in terms of latency, throughput, etc.; 

_ providing a predictable ORB core by instrumenting s 
and documenting the time behavior of the platform; 

_ reliability which denotes requirements that define 
acceptable behaviors for the distributed applica- 
tions in the presence of hardware and software fail- 
ures. In this case two types of reliability can be 10 
identified; the integrity state and the availability. 

_ manageability which denotes requirements that 
enable ease of development, deployment and oper- 
ation for complex applications. In this case main- 
tainability, (re)configurability and extensibility of is 
CORBA applications. 

Asynchronous Invocation model commonly used by 
IN applications. Thus, asynchronous and optionally iso- 
chronous invocation model is required with the ORB. 20 
The requirement here is a client side programming 
model which potentially supports a lightweight asyn- 
chronous communication mechanism incorporating a 
mandatory callback (or ORB "upcall" type mechanism) 
and optionally a "Futures" type programming model. 2s 

For the same object, both asynchronous and syn- 
chronous models should co-exist. The maximum con- 
curency level is defined in the configuration (e.g QoS 
parameters), and has to be controllable, with the possi- 
bility of queuing the request or returning an exception. 30 

A basic fault detection support should be provided 
by the ORB runtime for any object which needs it. This 
can be done by a timer which is implicit set and man- 
aged in the client process. 

35 

Flexibility and salability: 

The ORB should be able to support applications 
handling a large number of objects and should be able 
to support many simultaneous connections to remote 40 
objects. 

The memory cost of an unused remote interface 
reference in a given capsule (i.e. Unix process) should 
be of the order of a standard language pointer. 

A typical telecommunications environment com- 45 
prises objects of very different granularity's in both 
space (memory size) and time (object lifetime and dura- 
tion). A scaleable ORB should support objects at differ- 
ent levels of granularity's, and minimize the overhead 
associated with the handling of small and volatile so 
objects and of connections to remote objects. To 
achieve some of the ORB fault-tolerance and reliability, 
the CORBA object model could be enhanced to support 
group of objects or globally known as group communi- 
cation such as those described . 55 



Reliability and availability: 

To achieve the reliability requirements, the notion of 
replicated distributed objects can be introduced in 
CORBA. Thus the critical components of the application 
are implemented through replicated objects. This rep- 
lica management can be handled automatically by the 
ORB such that clients interacting with a given server 
object is not aware if it is replicated or not. The degree 
of replication can be determined by the desired level of 
reliability which can be measured with the number of 
maximum number of concurrent failures; the nature of 
the failure which can be typed (malicious or benign); 
and the type of reliability property being sought such as 
integrity or availability. High availability or Fault Toler- 
ance capabilities should be provided by CORBA for dis- 
tributed IN systems in order to ensure the same 
robustness as current IN systems. 

Timeliness requirements can be also achieved by 
the replica service. For example, applications that need 
to have bounded and predictable delays will be imple- 
mented through replicated objects. Each replica is able 
to process locally all of the methods defined for the 
object. In the absence of failure, a client can use any of 
the responses to a method Invocation as its result, (the 
invocations in this case is perform synchronously). To 
achieve this, the ORB will have a modular structure 
allowing the implementation of differents profiles, 
depending on application or services requirements. 
These profiles give an abstraction of the resources pro- 
vided by the underlying operating system. One of the 
ORB module will be a failure detector which is at the 
lower level of the ORB structure. And a response Invo- 
cation delay beyond a certain threshold are classified as 
failure. Thus, client is able to trade off reliability for time- 
liness, the shorter the threshold, the tighter the bounds 
on delays. By replicating an object in a sufficient number 
of times, client is able to meet both timeliness and relia- 
bility requirements simultaneously. 

Here, we have identified a requirement for a replica- 
tion service with correctness, safety and liveness prop- 
erties; and a failure detector module which is part of the 
ORB core. 

Performance: 

Performance of IN are measured in number of calls 
per second for service nodes and intelligent peripherals; 
and number of transaction per second for signaling con- 
trol point. These calls and transactions may involve mul- 
tiple messages exchanged between an SSP and the 
Intelligent Layer. To obtain the actual performance of 
legacy IN systems, real-time performance of the ORB is 
required for the use of distributed processing in IN sys- 
tems as well as its distribution on a geographical scale 
(non centralized IN systems). To achieve better per- 
formance for IN distributed systems, the ORB call over- 
head should be reduced, and the performance level that 
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the ORB must achieve in terms of latency, throughput, 
etc. should be defined and documented. 

Claims 

5 

1 . A method for providing a service for users of a tele- 
communication network, in which method service 
calls requesting the execution of the service for an 
respective one of the users are routed to a service 
switching exchange of the telecommunication net- 10 
work or are respectively routed to one of several 
service switching exchanges of the telecommunica- 
tion network and in which method a corespondent 
service request is sent by the respective service 
switching exchange, that has received the respec- is 
tive service call, to a service control facility or to one 

of several possible service control facilities, 
charaterized in that for each such service request 
received from the or each service switching 
exchange a service session object, which is able to 20 
interact and communicate via an object infrastruc- 
ture with other objects in a object oriented comput- 
ing environment, is created within the or each 
service control facility and the respective service 
session object controls the execution of the service 25 
for the respective service call. 

2. A method as claimed in claim 1, characterized in 
that the or each service switching exchange of the 
telecommunication network communicates with the 30 
or each service control facility according to the 
communication protocols of the Intelligent Network 
Architecture. 

3. A method as claimed in claim 1, characterized in as 
that each service session object interacts and com- 
municates as CORBA object via a CORBA object 
infrastructure with other objects for controlling the 
execution of the service. 

40 

4. A method as claimed in claim 1, characterized in 
that the service control facility or one of the service 
control facilities carries out the control of different 
services for users of the telecommunication net- - 
work. 45 

5. A method as claimed in claim 1, characterized in 
that the creation of each service session object is 
managed through a factory object. 

so 

6. A method as claimed in claim 1 or claim 4, charac- 
terized in that the creation of each service session 
object is managed by a service dedicated factory 
object. 

55 

7. A method as claimed in claim 5 or claim 6, charac- 
terized in that the factory object implements a life 
cycle policy for the service session object. 



8. A method as claimed in ctaim 7, characterized in 
that the factory object implements a creation on 
demand life cycle policy for the service session 
object. 

9. A method as claimed in claim 7, characterized in 
that the factory object implements activation on 
demand life cycle policy for the service session 
object. 

1 0. A method as claimed in claim 1 , characterized in 
that all functions for controlling the execution of the 
service are implemented by a dedicated CORBA 
service server. 

11. A method as claimed in claim 1, characterized in 
that the interface definition of the service session 
object is TCAP mapped over IDL 

12. A method as claimed in claim 1, characterized in 
that the service session object receives directly its 
own message invocations. 

13. A method as claimed in claim 1, characterized in 
that the service session object receives INAP mes- 
sages from the or each service switching exchange 
as message invocations. 

14. A method as claimed in claim 1, characterized in 
that each service session object runs in its own 
thread. 

1 5. A method for provisioning the execution of a service 
logic function within a service control facility of a tel- 
ecommunication systems, where service requests, 
that request the execution of the service logic func- 
tion, are received by the service control facility from 
at least one service switching exchange of the tele- 
communication system. 

charaterized in that for each such service request 
received from the at least one service switching 
exchange a service session object, which is able to 
interact and communicate via an object infrastruc- 
ture with other objects in a object oriented comput- 
ing environment, is created within the service 
control facility and the respective service session 
object handles the execution of the service logic 
function for the respective service request. 

16. A service control facility for connecting to one or 
several service switching exchanges of a telecom- 
munication network, where the service control facil- 
ity contains means for receiving service requests, 
that request the execution of a service for a user of 
the telecommunication network, from at least one of 
the service switching exchanges of the telecommu- 
nication network, 

charaterized by containing means for creating for 
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each such service request received from the at 
least one service switching exchange a service 
session object within the service control facility, 
means for enabling each service session object to 
interact and communicate via an object infrastruc- 5 
ture with other objects in an object oriented com- 
puting environment, and means for executing under 
control of the respective service session object a 
service logic function for the respective service 
request to 

17. The service control facility according to claim 16, 
characterized by containing a variable number of 
processing nodes for processing service session 
objects. is 

18. A processing node for a service control facility con- 
nected to one or several service switching 
exchanges of a telecomrmjnication network, where 
the processing node contains means for receiving so 
service requests, that request the execution of a 
service for a user of the telecommunication net- 
work, from at least one of the service switching 
exchanges of the telecommunication network, 
charaterized by containing means for creating for 25 
each such service request received from the at 
least one service switching exchange a service 
session object, means for enabling each service 
session object to interact and communicate via an 
object infrastructure with other objects in an object 30 
oriented computing environment, and means for 
executing under control of the respective service 
session object a service logic function for the 
respective service request. 

35 
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